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1. INTRODUCTION 



This paper addresses the question of how useful military software 
standards are for maintaining embedded computer software. Our discussion 
builds on previous studies of this topic (Schneidewind , 1982) which 
involved an analysis of the following United States Navy publications : 

° Military Standard (MIL-STD) 1679; 

° Weapons Specification (WS) 8506; and 

° Tactical Digital Systems Documentation Standards , SECNAVTNST 3560.1. 
(Note: It is recognized that, technically , only the first document is a 
standard. For ease of exposition , all three are referred to as "standards" 
in this paper.) The question posed by the previous research study was: 

Could these standards , accompanied by basic program documentation , such 
as a listing, provide adequate guidance for a new programmer to maintain 
software, such as that found in the Trident Command and Control Subsystem? 
These standards were reviewed with respect to the following criteria: 

0 design approaches for achieving good maintainability; 

0 specification and documentation requirements for achieving good 
maintainability ; and 

0 testing approaches for achieving good maintainability. 

With some significant qualifications, it was concluded that these standards 
were adequate for maintenance purposes. However, it was pointed out that 
these standards were developed for use in design and not for maintenance 
specifically. (The interested reader may find the details in the references 
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which have been cited.) 



Now, an excellent standard would recognize the linkage between soft- 
ware design and maintenance and would specify design practices that are 
conducive to maintenance. The problem seems to be that standards of the 
type which have been referenced were developed prior to the time when 
maintenance was recognized as an important phase of the software life 
cycle and prior to the realization that maintainability must be designed 
into the software. Software standards should be revised to reflect this 
important concept. Also, advances in software requirements analysis and 
design methodologies, coupled with the significant use of microcomputers 
in embedded computer systems , have led to the need to update military 
software standards to reflect the realities of newer design and programming 
environments. Improvement in design approach enhances maintainability; 
the use of microcomputers, on the other hand, presents new problems for 
the software development agency due to the limited software development 
tools which are available in many microcomputer software development 
facilities. However, it is an open question as to whether the increased 
use of microcomputers for embedded systems is aiding or retarding the 
production of maintainable software. Although many microcomputer software 
production facilities are low-level, oriented to assembly language program- 
ming, the trend is for microcomputer software to be developed on larger 
host machines, using elaborate program development tools on an interactive 
basis , and down loaded to a development system and eventually to the target 
machine (Ziegler, 1982) . This trend may lead in the future to more emphasis 
on chip certification and less on software validation. As contrasted to 
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advances in software design and programming methodology , it is not clear that 



software standards should be significantly changed just because computers 
get smaller and programming environments change. The desirable objectives 
of, for example, producing code which can be changed without upsetting 
the rest of the system remains valid independent of the particular form, 
size, speed or configuration of a hardware -software system. 

Transcending the aspects of improved software design methodology and 
changing computer technology, is the need to trace both errors in the 
software and design decisions (which many times are related to errors) to 
the pertinent technical information. The need for traceability is independent 
of software design methodology and the particular computer technology 
which is used in a system. However, proper use of methodology and technology 
can greatly improve traceability, particularly with regard to identifying 
the effects of changes to the software. 

Within the context of the question posed at the beginning of this 
section, we examine the usability of military software standards in the 
ensuing sections with respect to the following areas: 

° requirements analysis methodologies; 

° microcomputer software development; and 
° traceability. 

We conclude with recommendations concerning the effective utilization of 
these standards in an environment of changing methodology and technology . 



4 



2. EFFECTS OF REQUIREMENTS ANALYSIS SYSTEMS ON SOFTWARE STANDARDS 



One of the major efforts to improve the quality of software has focused 
on the development of formal software requirements analysis methodologies 
(Alford, 1977; Bell, 1977; Ross, 1977; Teichroew, 1977). Objectives of 
these and related systems are the following: 

° improved quality of documentation with regard to precision, consist- 
ency and completeness; 

° formal methods of specifying requirements, usually involving the 
use of a language or format for expressing requirements (Liskov, 
1975); and 

° separation of system functions so that related functions appear in 
the same module and unrelated functions appear in different modules, 
resulting in the creation of independent modules (Myers, 1978). 

A major ingredient of requirements analysis methodologies is computer- 5 
aided analysis, consisting of the following components: a language for 
expressing requirements; a data base for storing requirements and specifi- 
cations; an analysis and retrieval system for checking requirements 
consistency and completeness; and various types of graphics terminal and 
hardcopy outputs (Bell, 1977) . The emphasis of these systems is a language 
aimed at achieving formalism and consistency of expressing requirements. 
These methodologies do not address to a great extent strategies for 
translating requirements into a software design. 

An effort where design strategies and requirements analysis techniques 
are directed toward confining the effects of changes to software (hence, 
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improving maintainability) is the project of the Naval Research Laboratory 
(Britton, 1981; Heninger, 1978, 1980; Parker, 1980) to rewrite the soft- 
ware for the A-7E Aircraft, using the principles of information hiding, 
separation of concerns and abstract interfaces (Parnas, 1972, 1978; Hestor , 
1981; Britton, 1981). Central to this effort is the method for decomposing 
modules. The method proposed by Parnas (Parnas, 1972) is the following: 

° every module in the decomposition process is characterized by design 
decisions which are hidden from all other modules (the information 
hiding principle) ; this criterion does not decompose the system 
into modules on the basis of the time sequence of processing the 
modules; and 

° elements that are likely to change are identified and incorporated 
into separate modules (device interface modules) in order to mini- 
mize the effects of device changes on user modules. 

Myers (Myers, 1978), among others, has sounded a similar theme. He 
recommends that modules should be partitioned so that relationships between 
modules are minimized. In Myer's terms, this results in high module strength 
and weak module coupling, and leads to the desirable result of module 
independence. A major objective of these approaches is to reduce the 
ripple effect of software changes (that is, the effect on modules external 
to the changed module) . 
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2.1 STATUS OF STANDARDS RELATIVE TO REQUIREMENTS ANALYSIS SYSTEMS 



What is the status of the standards (1679, 8506, 3560.1) relative to 
specifying the use of requirements analysis methodologies and design 
techniques (e.g. , methods for module decomposition)? MIL-STD-1679 , 

Section 5.2, states that the design shall be a hierarchical structure with 
the highest level of control logic residing at the top of the hierarchy 
and computation functions residing at the lower levels. As stated by 
Myers (Myers, 1978), the objective is not simply partitioning modules into 
a hierarchy, but partitioning so that each module is as independent of 
other modules as possible. This procedure will result in confining the 
effects of change and, hence, make the software more maintainable. In 
addition, as indicated by Schneidewind (Schneidewind , 1982, NPS-54-82-002) , 
although the change in reporting and control procedures specified by 1679 
is excellent in Section 5.11.2, the coverage is inadequate regarding 
separation of software functions by anticipated degree of change. With 
regard to WS 8506, it makes brief mention of describing major functions 
and the dependency among functions in Section 5.2. This reference does 
not elaborate on why or how the information is to be used (Schneidewind, 
1982, NPS-54-82-002) . An important use of the information would be for 
decomposing a system into modules and for the related purpose of achieving 
module independence. The situation is worse in the case of SECNAVINST 
3560.1. This document is notable for the great amount of detail presented 
pertaining to function and interface descriptions, data exchange, program 
resource budgets, etc. (Schneidewind, 1982, NPS-59-82-003) . However, 
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there is an absence of material dealing with designing for change. 

In addition to the above gaps in coverage , the standards pre-date the 
use of software requirements analysis systems , such as those described 
by Alford (Alford, 1977). Naturally, the older the standard, the more 
obsolete it is relative to advances in requirements analysis methodologies 
and software design. So these remarks should not be construed as criticism 
of the standards, but as indications of the need to consider updating the 
standards for the purpose of bringing them into line with software engineer- 
ing techniques which look quite promising. It is necessary to emphasize 
that methods proposed by Pamas , Myers, Teichroew and others have not 
reached the stage of accepted practice by a large segment of the software 
engineering community. For one thing, there must be further demonstration 
of improvements in software maintainability on large systems before these 
procedures will graduate to the status of standard practice. However, we 
contend that the approach in standards development should be to lead rather 
than to follow developments in software engineering. There is obviously 
more risk associated with this policy, but its successful implementation 
can prevent a standard from being obsolete before it is even issued. 

In summary, with regard to the areas of requirements analysis and 
software design, the standards are weak and in need of upgrading to include 
the following requirements : 

° decomposition of a system into modules for the purpose of confining 
the effects of software changes by using techniques such as: 

- hiding device characteristics from user programs and, 

- designing modules so that related elements are contained in 
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the same module and unrelated elements are contained in different 



modules (high module strength and low module coupling) ; and 
° employment of a requirements analysis system for the purposes of: 

- standardizing the language in which requirements are stated, and 

- providing computer-aided tools for storing, analyzing and retrieving 
requirements to ensure consistency and completeness. 
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3. THE EFFECT OF MICROCOMPUTERS ON STANDARDS DEVELOPMENT 



As suggested in Section 1, standards development should be independ- 
ent of the characteristics of the hardware and software employed in an 
application. A standard should require the developer to employ sound 
software engineering practices. These techniques become 'sound' by evolving 
from theory to standard practice through a process of proposal, debate, 
demonstration, use, concensus and acceptance. This process should not be 
influenced by whether, for example, an application is implemented in a 
centralized main frame or a distributed microcomputer system. The aspect 
that is affected by the choice of technology is the ability of the developer 
to meet the standard (e.g., conforming to a requirement for using struc- 
tured programming with assembly language versus high level language) . For 
example, if crude program development and test tools are used for imple- 
menting microcomputer software, or any software for that matter, traceability 
will be difficult to achieve. More will be said about traceability in a 
later section. 

Concern about the peculiarities of microcomputer software development 
may evaporate in the near future. As mentioned in Section 1, the trend in 
microcomputer software development is toward using the types of tools which 
have been used for some time in the minicomputer and mainframe areas . For 
example , if we compare two publications which are only one year apart (Ogdin, 
1980) and (Markowitz, 1981), we find that the former, in describing micro- 
computer programming environments, stresses hexidecimal coding, prototyping 
systems, computer evaluation kits, portable front panels, single board 
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computers and microcomputer development systems. In contrast , Markowitz* s 
article describes the architecture of the iAPX 286 in terms of memory 
management, segmented memory, protection, and various priviledge levels - 
characteristics of large machines. Zeigler (Zeigler, 1981) talks about 
extensions to the ADA language which INTEL has developed in support of 
the 432 architecture. 

None of the standards makes reference to the use of microcomputers. 
This would obviously be the case for 3560.1 and 8506, since their publi- 
cation pre-dated significant use of microcomputers. Although 1679 was 
published during the era of microcomputers, mentioning the use of this 
technology in the standard would have been inappropriate. As stated by 
Cooper (Cooper, 1981) , in describing the development of 1679, the single 
most important rule of a MIL-STD is that it can only specify what is 
required, not how to satisfy a requirement . However, it must be noted 
that 1679 does not seem to be entirely faithful to this rule, since it 
calls for the use of structured programming constructs (Section 5.3), and 
top down design and high order languages (Section 5.5) , as examples of 
many "how to" provisions. 

Based on the reasons given in this section, we conclude that the 
standards should not be modified to incorporate provisions that deal with 
the development of microcomputer software for embedded computer systems. 
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4. APPROACHES FOR IMPROVING TRACEABILITY OF STANDARDS 



A prerequisite for achieving traceability and, hence, maintainability, 
is to have planned for the software to change when it was designed and to 
have designed the software correspondingly, so that changes can be easily 
traced through the documentation in order to identify the relevant inputs , 
outputs, data base, modes of operation, conditions, etc. The A-7E Aircraft 
documentation (Heninger, 1978) does a good job of providing traceability 
because it was designed with change in mind. Some of the formats which 
are useful for achieving traceability are the following: 

° Event Tables which relate modes, events, and actions? 

° Condition Tables which relate modes , conditions and actions or 
values ; and 

° Selector Tables which relate modes and mutually exclusive charac- 
teristics of modes. 

In the above, the following meanings apply: 

° mode - system state? 

° condition - expression whose value is true or false and characterizes 
the system for a measurable time? 

° event - a condition which changes from true to false or vice versa 
at a specific moment in time; 

° action - evaluation of a function? and 
° value - expression or* output data item value. 

In this system of documentation, if an event (e.g., ground distance 
to a reference point) were to change when the radar update mode is entered. 
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it would be possible to ascertain the fact that this combination affects 



an action taken by the pilot relative to cursor enable (output data item) . 
In general, design decisions, module decomposition and module dependencies 
are made explicit in the system of software design and documentation. 

Other useful aspects of the documentation include a dictionary of commonly 
used terms and a section dealing with subsets - a part of the system 
which is isolatable from the total system, performs part of the services 
provided by the total system and uses less computer resources than the 
total system. One of the ideas of subsets is to be able to reassemble a 
smaller system and thereby save on resources if the entire system is not 
utilized te.g. , a particular weapon is not available or used). 

Weaknesses in this system seem to lie in the areas of tracking changes 
in outputs to inputs and data bases, where applicable, and, in some cases, 
lack of clarity of definitions as they relate to various tables. Also, 
although we subscribe to the objectives of information hiding, which 
provides the underpinning of the A-7E project, it is our opinion that the 
design procedures and terminology which are necessary to implement infor- 
mation hiding could be confusing to software engineers. We prefer to 
think of the process of requirements analysis as making requirements 
explicit, rather than hiding certain ones, and to only embody a requirement 
in a module when the requirement is relevant to that module; otherwise, 
the requirement is implemented in a module where it is relevant. Require- 
ments which are common to two or more modules are contained within a 
separate module, rather than within the given modules themselves. Addi- 
tionally, requirements which are likely to change should be quarantined 
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and placed in a limited number of modules rather than being spread across 
many modules. 

Nevertheless, on the whole, the A-7E Aircraft project and a related 
project (Hester, 1981) would provide an excellent model for revising the 
standards to incorporate software design practices which specifically 
address the need to account for future change to the software. This would 
be a particularly powerful approach if coupled with the use of one of the 
requirements analysis systems (Ross, 1977) for providing computer-aided 
requirements analysis tools and for supporting the requirements analysis 
which must precede the software design. 

The primary author of MIL-STD 1679 (Cooper, 1981) feels that with 
only two years use, it would be premature to revise it. However, neither 
1679 nor the other standards are strong in the vital area of traceability 
(Schneidewind, 1982). We feel, therefore, that because the volatility of 
software is so great and affects maintenance so significantly, that a 
standard must explicitly provide for change in the design process in 
order to achieve traceability in the maintenance phase. Note that this 
characteristic of a standard is not the same thing as a change control 
procedure, which is a part of 1679. To use a medical analogy, the recommended 
approach involves using preventive medicine early in the life of a system 
in order to avoid emergency surgery at a later date. 
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5. CONCLUSIONS AND RECOMMENDATION 



Three important areas relative to software standards have been 
considered which potentially impact on software maintainability: 

(1) requirements analysis and software design methodologies; 

(2) microcomputer software; and 

(3) traceability. 

It is concluded that (1) and (3) should be improved in SECNAVTNST 3560. 1, 
WS8506 and MIL-STD 1679 and that (2) is not appropriate for inclusion in 
a standard. 

Furthermore, it is recommended that A7-E Aircraft software redesign 
project be used as a model for improving the standards relative to (1) and 
(3) . 
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